home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Software Vault: The Diamond Collection
/
The Diamond Collection (Software Vault)(Digital Impact).ISO
/
cdr37
/
fwklz202.zip
/
LOOKUP.DOC
< prev
next >
Wrap
Text File
|
1995-03-31
|
25KB
|
584 lines
LOOKUP(TM), LOOKUPZ(TM), and RCROSREF(TM) are part of
FWKCS(TM) Contents_Signature System, Ver. 2.02, 1995 Mar 31.
(C)Copyright Frederick W. Kantor 1989, 1995. All rights reserved.
Your use of any of these programs is at solely your own risk:
........................ C A V E A T O P E R A T O R ........................
L O O K U P
~~~~~~~~~~~
with
R c r o s r e f
~~~~~~~~~~~~~~~
and L O O K U P Z <---<< this one does not use a
~~~~~~~~~~~~~ registration key.
For on_line help,
type LOOKUP <enter>
LOOKUPZ <enter>
RCROSREF <enter>
Each of those commands will put
instructions onto the screen, with an
example you can use while you make your
entry.
The FWKCS(TM) Contents_Signature System, Versions 1.10 and
later, provides a special way for an electronic bulletin board
system ("BBS") to help you. "Lookup" provides you with a quick,
easy way to find out if that BBS has any file which matches a
particular file you have. This matching is tested quickly,
using contents_signatures which have much greater resolution
than is provided by the older 32_bit CRCs.
FWKCS Version 2.02's LOOKUPZ makes this support available
to persons who have only the LOOKUPZ.BAT program and PKWARE's
PKZIP.EXE -- plus, of course, a way to call a BBS which is
running FWKCS 2.00 or later.
You can then use Rcrosref to follow up on contents_
signature cross_references which a BBS may provide in replying
to your Lookup inquiry.
For a plain file, this ability to find matching file(s)
does not depend on the name or date of the file (to use
LOOKUPZ, put the plain file in a zipfile first).
For a zipfile, this ability to find matching file(s) does
not depend on the name or date of the zipfile, the amount of
compression of different files in it, the names or dates of the
files in it, zipped path information, file comments, the
zipfile comment, nor on the order in which the files appear in
the zipfile.
Before you upload a file or a zipfile to the BBS, you can
upload an "inquiry file" which Lookup or Lookupz makes for you.
The BBS then quickly tells you if it already has any of that
material, and, if so, in what file or zipfiles you can find
that material, and by what name it is called in each of those
places (which can be a different name in each place). You don't
have to waste your time or run up your telephone bill uploading
a file they already have.
Before you lose sleep looking for the missing instructions
for a computer game that also got renamed along the way, you
can use Lookup of Lookupz to look for the whole package on a
big BBS in seconds.
"Lookup(z)" and FWKCS work together to turn big BBSs into
multi_gigabyte high_speed reference libraries which you can
reach from the comfort of your home or office, or from a
portable computer -- even if you don't know the name of what
you are looking up.
How to use Lookup
~~~~~~~~~~~~~~~~~
You just type
LOOKUP FILENAME.EXE T1045.ZIP <enter> (for detailed reply)
or
LOOKUP FILENAME.EXE T1045.ZIP ! <enter> (for short reply)
where
FILENAME.EXE is the full filename and extension of
the file you want to look up
T1045.ZIP is any name you want to make up,
using the extension .ZIP
(if the file you want to look up is
located in the default directory with
the output file, then the output file
must have a different name than the
input file. For a way around this,
see Example 4, below.)
! is literal, to request a reply
without details
"Lookup" prepares a special output file, with the name you
choose. You then call the BBSs, and upload the special file
that Lookup made.
How to use Lookupz
~~~~~~~~~~~~~~~~~~
To use Lookupz, the BBS you are calling must be running
FWKCS 2.00 or later.
It's a lot like using Lookup:
You just type
LOOKUPZ FILES.ZIP T1045.ZIP <enter> (for detailed reply)
or
LOOKUPZ FILES.ZIP T1045.ZIP ! <enter> (for short reply)
where
FILES.ZIP contains up to 512 files to look up at one
time
T1045.ZIP is any name you want to make up,
using the extension .ZIP
! is literal, to request a reply
without details
If you are just interested in a short estimate as to
whether a file or zipfile would be sufficiently new to be
worth uploading, you can use the second format, which has the
exclamation point "!" in it. If you are communicating with a
BBS which is using FWKCS Ver. 1.15 or later, the reply omits
the detailed list of matching files. (That request for a short
reply is not accepted by earlier versions of FWKCS, and would
be rejected as defective.)
If you are using the top format (without the "!"), capture
the BBS's reply to a file, for use later. For discussion
below, we will assume that the captured reply is in a file
called BBS.CAP.
The BBS will tell you that the upload "failed" -- that
means that you don't get any upload credit for having sent it
-- but it will send you a special message prepared there by
FWKCS, telling you whether it found any matching contents_
signature(s), and, if so, in what file(s). Normally, the name
of the inquiry file you uploaded is available for use again.
It will display your input item, and below that either a
line which says "did not find cs_match", or two or more lines
which say something like, for example,
found:
FILENAME.EXT ZIPFILNM.ZIP D:
| | |
1 2 3 4 5 6
At these locations 1...6, you may see:
1. lower_case letters used as flags:
r cross_reference; in this case, the format for the rest of
the line is different, because it is used for carrying a
contents_signature to which cross_reference is made.
(see FWKCS202.REF, Auxiliary Function 3, option r)
this flag is used in Rcrosref, discussed below;
w wipe (remove if found in non_AV zipfiles): for example,
a known ad;
x exclude (reject file or zipfile): for example, known
commercial software (don't upload a file for which you
receive such an x flag, because it will be rejected);
others are listed in FWKCS202.REF under Special Column_17
Flags.
2. the name of a file in a zipfile, in which case the zipfile
name is in location 4; or
the name of a zipfile, in which case "z cs" appears in
location 4; or
the name of a non_zip file, in which case "f cs" appears in
location 4.
3. lower_case letters used to indicate Authenticity
Verification and/or encryption:
a the file in 2 has authenticity verification in a zipfile,
in which case the zipfile name appears in 4 and has a
lower_case v in location 5
p the file in 2 is an apparently encrypted ("private") file
in a zipfile
u the file in 2 has authenticity verification and
apparently encrypted material;
if the name of a zipfile appears in location 4, then
the file in location 2 is contained in that zipfile
if "z cs" appears in location 4, then the file in
location 2 is a zipfile which contains at least one
file which has authenticity verification and at least
one file which is apparently encrypted (possibly
different files)
v the file in location 2 is a zipfile which contains at
least one file which has authenticity verification, and
does not contain any apparently encrypted file.
4. the name of a zipfile which contains the file named in
location 2; or
"f cs" indicating that the file in location 2 is not a
zipfile
"z cs" indicating that the file in location 2 is a zipfile
5. may contain a lower_case "v", in which case the file in
location 4 is a zipfile which contains at least one file
which has authenticity verification.
6. may contain a drive_letter and colon, e.g., D:, indicating
that the matching contents_signature which was found belongs
to a file which may be currently available on the BBS
if there is no drive letter with colon, that often means
that the contents_signature which was found came from a file
which is not available on the BBS, such as a file which has
been retired from the system; but if the BBS accepts
zipfiles which contain other zipfiles, and a zipfile is
named in location 4 (above), then the absence of drive
letter with colon might mean that the contents_signature
came from a file which is contained in a zipfile which is,
itself, contained in the zipfile named in location 4: for
this reason, it is suggested that you test for the existence
of the zipfile named in location 4 (e.g., by a filename
search on the BBS).
(For use of "a" and "v", see Example 3, below).
Also, it may tell you (in words) if any of the matching
material you asked about was marked for automatic total
exclusion on that BBS (for example, commercial software might
be marked for automatic exclusion). Whether or not you are
told in words, any such exclusion is shown in a full listing by
a lower_case "x" in the left column next to each such item
found.
There may be a special marker to tell you if one or more
parts of the material you asked about was marked for Wiping
(automatic removal from uploaded non_AV zipfiles). These are
marked with a lower_case "w" in the left column next to the
item found. For example, known spurious advertisements may be
marked for automatic removal.
Depending on options set up on the particular BBS you call,
it may tell you whether there would be a question as to
sufficient novelty were you to upload the material you asked
about. Different BBSs have different settings for this. Of
course, if you are interested in downloading rather than
uploading, such a comment does not apply to you, but the BBS
doesn't know the reason for your call.
Other information is also provided.
Example 1
~~~~~~~~~
Suppose you want to find out if a single, plain (non_zip)
file is contained in one of the zipfiles on a big BBS.
Type LOOKUP file t43012.zip <enter>
Upload T43012.ZIP to the BBS.
Capture the screen to a file for use later, and read the
message as it comes in.
Here is one example of a message back, where it did not find
any matching contents_signature:
--- contents_signature(s) from the file T43012.ZIP which
you just uploaded were compared with those of prior file(s).
- re your request for a contents_signature search:
- did not find any contents_signature match.
--- the file T43012.ZIP has been deleted.
The message you actually receive may be more "personalized",
addressing you by your first name.
Please be aware that, although the above message says that
the file has been deleted, certain bulletin board software does
not operate correctly if the filename is also deleted; for
example, Mustang Software's Wildcat requires that the filename
remain, so a substitute file is used to replace the deleted
file. However, because the file was treated as rejected, the
further availability of that name for re_use follows the same
treatment as for other rejected files.
Clark Development Co.'s PCBoard does not require that the
filename remain, and you are free to use that filename again.
Example 2
~~~~~~~~~~
Suppose you do this:
LOOKUP FOO T43005.ZIP <enter>
Upload T43005.ZIP to the BBS
and receive:
--- contents_signature(s) from the file T43005.ZIP which
you just uploaded were compared with those of prior file(s).
- re your request for a contents_signature search:
- a contents_signature match was found for each input file;
the input file(s) might be not ZIPped.
==============================================================
> Referring to C:\CS\CSLIST.SRT ------------------------------
==============================================================
6416DCA5 2AB FOO f cs C:\CS\CSK\3\1
did not find cs_match
==============================================================
> Referring to C:\CS\CSLIST1.SRT -----------------------------
==============================================================
6416DCA5 2AB FOO f cs C:\CS\CSK\3\1
found:
FOOF f cs C:
==============================================================
--- the file T43005.ZIP has been deleted.
The "f cs" means that the "file contents_signature" was for
a plain file.
The "C:" to the right of the item found means that the
contents_signature entry is not carried forward from a file
which has been retired from the BBS. If the file has been
retired, its contents_signature is normally carried forward
without a drive letter and without the ":". The contents_
signature continues to serve in preventing old material from
accidentally being accepted as if it were new, and the space
left by removing the retired file is available for current
material. (For instance, this may happen when an author issues
a revised version of one of his/her programs.)
Example 3
~~~~~~~~~
Suppose you do this:
LOOKUP FWKDG108.SNT M.M <enter>
"Upload" M.M to your own local system
and receive:
--- contents_signature(s) from the file M.M which
you just uploaded were compared with those of prior file(s).
- re your request for a contents_signature search:
- a contents_signature match was found for every contained file, but
not for zipfile_contents_signature; the contents may have appeared in
a larger prior ZIP, or been spread among more than one prior ZIPfiles.
==============================================================
> Referring to C:\CS\CSLIST.SRT ------------------------------
==============================================================
168CA0F0 295B FWKDG108.SNT z cs C:\ZIPS
did not find cs_match
**
299209E9 B59 FWKDG.COM FWKDG108.SNT C:\ZIPS
found:
FWKDG.COM FWKDG1A8.ZIP C:
FWKDG.COM aFWKCS104.ZIPvC:
**
5FB1021A 49 FWKDG108.BAT FWKDG108.SNT C:\ZIPS
found:
FWKDG108.BAT FWKDG1A8.ZIP C:
FWKDG108.BATaFWKCS104.ZIPvC:
**
B8783FE7 1ADB FWKDG108.DOC FWKDG108.SNT C:\ZIPS
found:
FWKDG108.DOC FWKDG1A8.ZIP C:
**
D4D15506 2DE FWKDG108.SCR FWKDG108.SNT C:\ZIPS
found:
FWKDG108.SCR FWKDG1A8.ZIP C:
FWKDG108.SCRaFWKCS104.ZIPvC:
==============================================================
> Referring to C:\CS\CSLIST1.SRT -----------------------------
==============================================================
168CA0F0 295B FWKDG108.SNT z cs C:\ZIPS
did not find cs_match
**
299209E9 B59 FWKDG.COM FWKDG108.SNT C:\ZIPS
did not find cs_match
**
5FB1021A 49 FWKDG108.BAT FWKDG108.SNT C:\ZIPS
did not find cs_match
**
B8783FE7 1ADB FWKDG108.DOC FWKDG108.SNT C:\ZIPS
did not find cs_match
**
D4D15506 2DE FWKDG108.SCR FWKDG108.SNT C:\ZIPS
did not find cs_match
==============================================================
--- the file M.M has been deleted.
The items which appear in two columns directly below the word
"found:" are
if there is a filename in the right column, then it is the
name of the zipfile which contains the file listed next to it
in the left column -- the cs_match (contents_signature match)
was made to the file in the left column.
if there is no filename in the right column, you typically
will see either
"f cs" indicating a plain_file contents_signature
or
"z cs" indicating a zipfile_contents_signature, in
which all the files in a zipfile are taken
together in a special way. (For technical
discussion of this, see FWKCS202.REF.)
In these cases, too, the cs_match is made to the file in the
left column.
Example 4
~~~~~~~~~
Depending on the kind of bulletin board software used by
the BBS you are calling, you may be able to save connect_time
in testing whether a file or zipfile would be acceptable as an
upload to a BBS, by using Lookup to ask if the contents are
already known to the BBS, and using the same filename as the
one you want to upload later. Because the inquiry file is
treated as "rejected", various bulletin board systems treat the
name which was used for it as being available for another
upload.
If you can use this method on the BBS you're calling, here
is how to do it:
Start with the file you want to inquire about in a
different directory than you are working in. For example,
default <-- where you are now
|
sub1\FOO.ZIP <-- the file you want to get
information about
Type LOOKUP sub1\foo.zip foo.zip ! <enter>
(the "!" is to request a short reply)
Then upload this new FOO.ZIP which was created in the default
directory, to find out whether you should upload the original
FOO.ZIP.
Example 5
~~~~~~~~~
If the BBS you are calling is using FWKCS Version 1.20 or
later, and you wish to make an inquiry as to whether several
non_zip files are recognized on a BBS, you can ask re up to 512
such files in one inquiry, using wildcards. For example, if
you put all, and only, those files into your sub1 directory
(see example 4, above), you can then type
LOOKUP sub1\*.* T43005.ZIP <enter>
and then send T43005.ZIP (or whatever name you use) as your
inquiry.
Notes: do not ask re both a zipfile and a non_zip file in
the same remote inquiry;
do not ask re multiple zipfiles in the same remote
inquiry.
How to use Rcrosref
~~~~~~~~~~~~~~~~~~~
You just type
RCROSREF BBS.CAP T1045.ZIP <enter>
where
BBS.CAP is the full filename and extension of
the file you used to capture the BBS's
reply to your Lookup
T1045.ZIP is any name you want to make up, using
the extension .ZIP
If Rcrosref does not find any contents_signature cross_
reference in the BBS.CAP reply file, it will tell you so, and
will not make the new inquiry zipfile.
If Rcrosref makes a new inquiry zipfile, just upload it to the
same BBS, and capture the reply in a new BBS.CAP, etc.
Note: One way of organizing a cross_reference system is to
use "nodes" to which many related files are linked. In
that case, the first reply to a Lookup inquiry may
include a small number of references to one or more
such nodes. The first Rcrosref inquiry based on that
reply may bring back a large number of cross_references
from those nodes which were cited. The second Rcrosref
inquiry may then bring back the names of the files
(and, if they are contained in zipfiles, the names of
zipfiles in which they can be found) for downloading.
(The maximum number of input items for a single remote
contents_signature search is 512. See Auxiliary
Function 5, option i, in FWKCS202.REF.)
-----------------------------------------------------------------------
Technical:
~~~~~~~~~~
To support remote inquiry operations, the BBS must be running
FWKCS Version 1.10 or later, with option i (remote Inquiry)
active when processing uploads. To support the terse reply ("!")
option, the BBS must be running FWKCS Version 1.15 or later.
To support remote inquiries prepared using Lookupz, the BBS
must be running FWKCS Version 2.00 or later.
The flags in the left column are the special Column_17 flags,
described in FWKCS202.REF.
The contents_signature format, and the meaning of the fcs and
zcs notation, are explained in FWKCS202.REF; the cross_
reference structure is explained there under Auxiliary Function
3, option r.
The statistical resolution is discussed in FWKCS202.REF, with
diagrams. On a large BBS, this typically has a statistical
resolution more than one thousand times as good as the best
that would be provided solely by a 32_bit CRC. It removes
the CRC effect of accidentally mistaking for each other files
which have different lengths. A new contents_signature was
introduced because the 32_bit CRC does not represent enough
information to meet the needs of large electronic bulletin
board systems, for reasons which are explained in FWKCS202.REF.
"Lookup", "Lookupz", and "Rcrosref" pass these benefits on to
you.